<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Breaking changes in 7.0 | ElasticSearch 7.7 权威指南中文版</title>
	<meta name="keywords" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <meta name="description" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
	<link rel="stylesheet" type="text/css" href="../static/styles.css" />
	<script>
	var _link = 'breaking-changes-7.0.html';
    </script>
</head>
<body>
<div class="main-container">
    <section id="content">
        <div class="content-wrapper">
            <section id="guide" lang="zh_cn">
                <div class="container">
                    <div class="row">
                        <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                            <div style="color:gray; word-break: break-all; font-size:12px;">原英文版地址: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.7/breaking-changes-7.0.html" rel="nofollow" target="_blank">https://www.elastic.co/guide/en/elasticsearch/reference/7.7/breaking-changes-7.0.html</a>, 原文档版权归 www.elastic.co 所有<br/>本地英文版地址: <a href="../en/breaking-changes-7.0.html" rel="nofollow" target="_blank">../en/breaking-changes-7.0.html</a></div>
                        <!-- start body -->
                  <div class="page_header">
<strong>重要</strong>: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html" rel="nofollow">当前版本文档</a>。
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="breaking-changes.html">Breaking changes</a></span>
»
<span class="breadcrumb-node">Breaking changes in 7.0</span>
</div>
<div class="navheader">
<span class="prev">
<a href="breaking-changes-7.1.html">« Breaking changes in 7.1</a>
</span>
<span class="next">
<a href="migrate-to-java-time.html">Java time migration guide »</a>
</span>
</div>
<div class="chapter">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="breaking-changes-7.0"></a>Breaking changes in 7.0<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0.asciidoc">edit</a>
</h2>
</div></div></div>

<p>This section discusses the changes that you need to be aware of when migrating
your application to Elasticsearch 7.0.</p>
<p>See also <a class="xref" href="release-highlights.html" title="7.7版本的新特性"><em>7.7版本的新特性</em></a> and <a class="xref" href="es-release-notes.html" title="Release notes">Release notes</a>.</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_aggregations_changes" title="Aggregations changes">Aggregations changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_cluster_changes" title="Cluster changes">Cluster changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_discovery_changes" title="Discovery changes">Discovery changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_indices_changes" title="Indices changes">Indices changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_ingest_changes" title="API changes">API changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_mappings_changes" title="Mapping changes">Mapping changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_ml_changes" title="ML changes">ML changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_search_changes" title="Search and Query DSL changes">Search and Query DSL changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_suggesters_changes" title="Suggesters changes">Suggesters changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_packaging_changes" title="Packaging changes">Packaging changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_plugins_changes" title="Plugins changes">Plugins changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_analysis_changes" title="Analysis changes">Analysis changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_api_changes" title="API changes">API changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_java_changes" title="Java API changes">Java API changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_settings_changes" title="Settings changes">Settings changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_scripting_changes" title="Scripting changes">Scripting changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_snapshotstats_changes" title="Snapshot stats changes">Snapshot stats changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_restclient_changes" title="High-level REST client changes">High-level REST client changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_low_level_restclient_changes" title="Low-level REST client changes">Low-level REST client changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_logging_changes" title="Logging changes">Logging changes</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_node_changes" title="Node start up">Node start up</a>
</li>
<li class="listitem">
<a class="xref" href="breaking-changes-7.0.html#breaking_70_java_time_changes" title="Replacing Joda-Time with java time">Replacing Joda-Time with java time</a>
</li>
</ul>
</div>
<h3>
<a id="_indices_created_before_7_0"></a>Indices created before 7.0<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0.asciidoc">edit</a>
</h3>
<p>Elasticsearch 7.0 can read indices created in version 6.0 or above.  An
Elasticsearch 7.0 node will not start in the presence of indices created in a
version of Elasticsearch before 6.0.</p>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<h3>Reindex indices from Elasticsearch 5.x or before</h3>
<p>Indices created in Elasticsearch 5.x or before will need to be reindexed with
Elasticsearch 6.x in order to be readable by Elasticsearch 7.x.</p>
</div>
</div>
<h3>
<a id="breaking_70_aggregations_changes"></a>Aggregations changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h3>
<h4>
<a id="removed-global-ordinals-hash-and-global-ordinals-low-cardinality-terms-agg"></a>Deprecated <code class="literal">global_ordinals_hash</code> and <code class="literal">global_ordinals_low_cardinality</code> execution hints for terms aggregations have been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>These <code class="literal">execution_hint</code> are removed and should be replaced by <code class="literal">global_ordinals</code>.</p>
<h4>
<a id="search-max-buckets-cluster-setting"></a><code class="literal">search.max_buckets</code> in the cluster setting<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>The dynamic cluster setting named <code class="literal">search.max_buckets</code> now defaults
to 10,000 (instead of unlimited in the previous version).
Requests that try to return more than the limit will fail with an exception.</p>
<h4>
<a id="missing-option-removed-composite-agg"></a><code class="literal">missing</code> option of the <code class="literal">composite</code> aggregation has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>The <code class="literal">missing</code> option of the <code class="literal">composite</code> aggregation, deprecated in 6.x,
has been removed. <code class="literal">missing_bucket</code> should be used instead.</p>
<h4>
<a id="replace-params-agg-with-state-context-variable"></a>Replaced <code class="literal">params._agg</code> with <code class="literal">state</code> context variable in scripted metric aggregations<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>The object used to share aggregation state between the scripts in a Scripted Metric
Aggregation is now a variable called <code class="literal">state</code> available in the script context, rather than
being provided via the <code class="literal">params</code> object as <code class="literal">params._agg</code>.</p>
<h4>
<a id="reduce-script-combine-script-params-mandatory"></a>Make metric aggregation script parameters <code class="literal">reduce_script</code> and <code class="literal">combine_script</code> mandatory<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>The metric aggregation has been changed to require these two script parameters to ensure users are
explicitly defining how their data is processed.</p>
<h4>
<a id="percentiles-percentile-ranks-return-null-instead-nan"></a><code class="literal">percentiles</code> and <code class="literal">percentile_ranks</code> now return <code class="literal">null</code> instead of <code class="literal">NaN</code><a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>The <code class="literal">percentiles</code> and <code class="literal">percentile_ranks</code> aggregations used to return <code class="literal">NaN</code> in
the response if they were applied to an empty set of values. Because <code class="literal">NaN</code> is
not officially supported by JSON, it has been replaced with <code class="literal">null</code>.</p>
<h4>
<a id="stats-extended-stats-return-zero-instead-null"></a><code class="literal">stats</code> and <code class="literal">extended_stats</code> now return 0 instead of <code class="literal">null</code> for zero docs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/aggregations.asciidoc">edit</a>
</h4>
<p>When the <code class="literal">stats</code> and <code class="literal">extended_stats</code> aggregations collected zero docs (<code class="literal">doc_count: 0</code>),
their value would be <code class="literal">null</code>.  This was in contrast with the <code class="literal">sum</code> aggregation which
would return <code class="literal">0</code>.  The <code class="literal">stats</code> and <code class="literal">extended_stats</code> aggs are now consistent with
<code class="literal">sum</code> and also return zero.</p>
<h3>
<a id="breaking_70_analysis_changes"></a>Analysis changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h3>
<h4>
<a id="limit-number-of-tokens-produced-by-analyze"></a>Limiting the number of tokens produced by _analyze<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h4>
<p>To safeguard against out of memory errors, the number of tokens that can be produced
using the <code class="literal">_analyze</code> endpoint has been limited to 10000. This default limit can be changed
for a particular index with the index setting <code class="literal">index.analyze.max_token_count</code>.</p>
<h4>
<a id="_limiting_the_length_of_an_analyzed_text_during_highlighting"></a>Limiting the length of an analyzed text during highlighting<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h4>
<p>Highlighting a text that was indexed without offsets or term vectors,
requires analysis of this text in memory real time during the search request.
For large texts this analysis may take substantial amount of time and memory.
To protect against this, the maximum number of characters that will be analyzed has been
limited to 1000000. This default limit can be changed
for a particular index with the index setting <code class="literal">index.highlight.max_analyzed_offset</code>.</p>
<h4>
<a id="delimited-payload-filter-renaming"></a><code class="literal">delimited_payload_filter</code> renaming<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h4>
<p>The <code class="literal">delimited_payload_filter</code> was deprecated and renamed to <code class="literal">delimited_payload</code> in 6.2.
Using it in indices created before 7.0 will issue deprecation warnings. Using the old
name in new indices created in 7.0 will throw an error. Use the new name <code class="literal">delimited_payload</code>
instead.</p>
<h4>
<a id="standard-filter-removed"></a><code class="literal">standard</code> filter has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h4>
<p>The <code class="literal">standard</code> token filter has been removed because it doesn’t change anything in the stream.</p>
<h4>
<a id="_deprecated_standard_html_strip_analyzer"></a>Deprecated standard_html_strip analyzer<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h4>
<p>The <code class="literal">standard_html_strip</code> analyzer has been deprecated, and should be replaced
with a combination of the <code class="literal">standard</code> tokenizer and <code class="literal">html_strip</code> char_filter.
Indexes created using this analyzer will still be readable in elasticsearch 7.0,
but it will not be possible to create new indexes using it.</p>
<h4>
<a id="deprecated-ngram-edgengram-token-filter-cannot-be-used"></a>The deprecated <code class="literal">nGram</code> and <code class="literal">edgeNGram</code> token filter cannot be used on new indices<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/analysis.asciidoc">edit</a>
</h4>
<p>The <code class="literal">nGram</code> and <code class="literal">edgeNGram</code> token filter names have been deprecated in an earlier 6.x version.
Indexes created using these token filters will still be readable in elasticsearch 7.0 but indexing
documents using those filter names will issue a deprecation warning. Using the deprecated names on
new indices starting with version 7.0.0 will be prohibited and throw an error when indexing
or analyzing documents. Both names should be replaced by <code class="literal">ngram</code> or <code class="literal">edge_ngram</code> respectively.</p>
<h3>
<a id="breaking_70_cluster_changes"></a>Cluster changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/cluster.asciidoc">edit</a>
</h3>
<h4>
<a id="_literal_literal_is_no_longer_allowed_in_cluster_name"></a><code class="literal">:</code> is no longer allowed in cluster name<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/cluster.asciidoc">edit</a>
</h4>
<p>Due to cross-cluster search using <code class="literal">:</code> to separate a cluster and index name,
cluster names may no longer contain <code class="literal">:</code>.</p>
<h4>
<a id="new-default-wait-for-active-shards-param"></a>New default for <code class="literal">wait_for_active_shards</code> parameter of the open index command<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/cluster.asciidoc">edit</a>
</h4>
<p>The default value for the <code class="literal">wait_for_active_shards</code> parameter of the open index API
is changed from 0 to 1, which means that the command will now by default wait for all
primary shards of the opened index to be allocated.</p>
<h4>
<a id="shard-preferences-removed"></a>Shard preferences <code class="literal">_primary</code>, <code class="literal">_primary_first</code>, <code class="literal">_replica</code>, and <code class="literal">_replica_first</code> are removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/cluster.asciidoc">edit</a>
</h4>
<p>These shard preferences are removed in favour of the <code class="literal">_prefer_nodes</code> and <code class="literal">_only_nodes</code> preferences.</p>
<h4>
<a id="_cluster_wide_shard_soft_limit"></a>Cluster-wide shard soft limit<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/cluster.asciidoc">edit</a>
</h4>
<p>Clusters now have soft limits on the total number of open shards in the cluster
based on the number of nodes and the <code class="literal">cluster.max_shards_per_node</code> cluster
setting, to prevent accidental operations that would destabilize the cluster.
More information can be found in the <a class="xref" href="misc-cluster.html" title="Miscellaneous cluster settings">documentation for that setting</a>.</p>
<h3>
<a id="breaking_70_discovery_changes"></a>Discovery changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h3>
<h4>
<a id="_cluster_bootstrapping_is_required_if_discovery_is_configured"></a>Cluster bootstrapping is required if discovery is configured<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h4>
<p>The first time a cluster is started, <code class="literal">cluster.initial_master_nodes</code> must be set
to perform cluster bootstrapping. It should contain the names of the
master-eligible nodes in the initial cluster and be defined on every
master-eligible node in the cluster. See <a class="xref" href="discovery-settings.html" title="Important discovery and cluster formation settings">the discovery
settings summary</a> for an example, and the
<a class="xref" href="modules-discovery-bootstrap-cluster.html" title="Bootstrapping a cluster">cluster bootstrapping reference
documentation</a> describes this setting in more detail.</p>
<p>The <code class="literal">discovery.zen.minimum_master_nodes</code> setting is permitted, but ignored, on
7.x nodes.</p>
<h4>
<a id="_removing_master_eligible_nodes_sometimes_requires_voting_exclusions"></a>Removing master-eligible nodes sometimes requires voting exclusions<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h4>
<p>If you wish to remove half or more of the master-eligible nodes from a cluster,
you must first exclude the affected nodes from the voting configuration using
the <a class="xref" href="modules-discovery-adding-removing-nodes.html" title="Adding and removing nodes">voting config exclusions API</a>.
If you remove fewer than half of the master-eligible nodes at the same time,
voting exclusions are not required.  If you remove only master-ineligible nodes
such as data-only nodes or coordinating-only nodes, voting exclusions are not
required. Likewise, if you add nodes to the cluster, voting exclusions are not
required.</p>
<h4>
<a id="_discovery_configuration_is_required_in_production"></a>Discovery configuration is required in production<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h4>
<p>Production deployments of Elasticsearch now require at least one of the
following settings to be specified in the <code class="literal">elasticsearch.yml</code> configuration
file:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">discovery.seed_hosts</code>
</li>
<li class="listitem">
<code class="literal">discovery.seed_providers</code>
</li>
<li class="listitem">
<code class="literal">cluster.initial_master_nodes</code>
</li>
<li class="listitem">
<code class="literal">discovery.zen.ping.unicast.hosts</code>
</li>
<li class="listitem">
<code class="literal">discovery.zen.hosts_provider</code>
</li>
</ul>
</div>
<p>The first three settings in this list are only available in versions 7.0 and
above. If you are preparing to upgrade from an earlier version, you must set
<code class="literal">discovery.zen.ping.unicast.hosts</code> or <code class="literal">discovery.zen.hosts_provider</code>.</p>
<h4>
<a id="new-name-no-master-block-setting"></a>New name for <code class="literal">no_master_block</code> setting<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h4>
<p>The <code class="literal">discovery.zen.no_master_block</code> setting is now known as
<code class="literal">cluster.no_master_block</code>. Any value set for <code class="literal">discovery.zen.no_master_block</code> is
now ignored. You should remove this setting and, if needed, set
<code class="literal">cluster.no_master_block</code> appropriately after the upgrade.</p>
<h4>
<a id="_reduced_default_timeouts_for_fault_detection"></a>Reduced default timeouts for fault detection<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h4>
<p>By default the <a class="xref" href="cluster-fault-detection.html" title="Cluster fault detection">cluster fault detection</a> subsystem
now considers a node to be faulty if it fails to respond to 3 consecutive
pings, each of which times out after 10 seconds. Thus a node that is
unresponsive for longer than 30 seconds is liable to be removed from the
cluster. Previously the default timeout for each ping was 30 seconds, so that
an unresponsive node might be kept in the cluster for over 90 seconds.</p>
<h4>
<a id="_master_ineligible_nodes_are_ignored_by_discovery"></a>Master-ineligible nodes are ignored by discovery<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/discovery.asciidoc">edit</a>
</h4>
<p>In earlier versions it was possible to use master-ineligible nodes during the
discovery process, either as seed nodes or to transfer discovery gossip
indirectly between the master-eligible nodes. Clusters that relied on
master-ineligible nodes like this were fragile and unable to automatically
recover from some kinds of failure. Discovery now involves only the
master-eligible nodes in the cluster so that it is not possible to rely on
master-ineligible nodes like this. You should configure
<a class="xref" href="modules-discovery-hosts-providers.html" title="Discovery"><code class="literal">discovery.seed_hosts</code> or another seed
hosts provider</a> to provide the addresses of all the master-eligible nodes in
your cluster.</p>
<h3>
<a id="breaking_70_ingest_changes"></a>API changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/ingest.asciidoc">edit</a>
</h3>
<h4>
<a id="_ingest_configuration_exception_information_is_now_transmitted_in_metadata_field"></a>Ingest configuration exception information is now transmitted in metadata field<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/ingest.asciidoc">edit</a>
</h4>
<p>Previously, some ingest configuration exception information about ingest processors
was sent to the client in the HTTP headers, which is inconsistent with how
exceptions are conveyed in other parts of Elasticsearch.</p>
<p>Configuration exception information is now conveyed as a field in the response
body.</p>
<h4>
<a id="_ingest_plugin_special_handling_has_been_removed"></a>Ingest plugin special handling has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/ingest.asciidoc">edit</a>
</h4>
<p>There was some special handling for installing and removing the <code class="literal">ingest-geoip</code> and
<code class="literal">ingest-user-agent</code> plugins after they were converted to modules. This special handling
was done to minimize breaking users in a minor release, and would exit with a status code
zero to avoid breaking automation.</p>
<p>This special handling has now been removed.</p>
<h3>
<a id="breaking_70_indices_changes"></a>Indices changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h3>
<h4>
<a id="_index_creation_no_longer_defaults_to_five_shards"></a>Index creation no longer defaults to five shards<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Previous versions of Elasticsearch defaulted to creating five shards per index.
Starting with 7.0.0, the default is now one shard per index.</p>
<h4>
<a id="_literal_literal_is_no_longer_allowed_in_index_name"></a><code class="literal">:</code> is no longer allowed in index name<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Due to cross-cluster search using <code class="literal">:</code> to separate a cluster and index name,
index names may no longer contain <code class="literal">:</code>.</p>
<h4>
<a id="index-unassigned-node-left-delayed-timeout-no-longer-negative"></a><code class="literal">index.unassigned.node_left.delayed_timeout</code> may no longer be negative<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Negative values were interpreted as zero in earlier versions but are no
longer accepted.</p>
<h4>
<a id="flush-force-merge-no-longer-refresh"></a><code class="literal">_flush</code> and <code class="literal">_force_merge</code> will no longer refresh<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>In previous versions issuing a <code class="literal">_flush</code> or <code class="literal">_force_merge</code> (with <code class="literal">flush=true</code>)
had the undocumented side-effect of refreshing the index which made new documents
visible to searches and non-realtime GET operations. From now on these operations
don’t have this side-effect anymore. To make documents visible an explicit <code class="literal">_refresh</code>
call is needed unless the index is refreshed by the internal scheduler.</p>
<h4>
<a id="_limit_to_the_difference_between_max_size_and_min_size_in_ngramtokenfilter_and_ngramtokenizer"></a>Limit to the difference between max_size and min_size in NGramTokenFilter and NGramTokenizer<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>To safeguard against creating too many index terms, the difference between <code class="literal">max_ngram</code> and
<code class="literal">min_ngram</code> in <code class="literal">NGramTokenFilter</code> and <code class="literal">NGramTokenizer</code> has been limited to 1. This default
limit can be changed with the index setting <code class="literal">index.max_ngram_diff</code>. Note that if the limit is
exceeded a error is thrown only for new indices. For existing pre-7.0 indices, a deprecation
warning is logged.</p>
<h4>
<a id="_limit_to_the_difference_between_max_shingle_size_and_min_shingle_size_in_shingletokenfilter"></a>Limit to the difference between max_shingle_size and min_shingle_size in ShingleTokenFilter<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>To safeguard against creating too many tokens, the difference between <code class="literal">max_shingle_size</code> and
<code class="literal">min_shingle_size</code> in <code class="literal">ShingleTokenFilter</code> has been limited to 3. This default
limit can be changed with the index setting <code class="literal">index.max_shingle_diff</code>. Note that if the limit is
exceeded a error is thrown only for new indices. For existing pre-7.0 indices, a deprecation
warning is logged.</p>
<h4>
<a id="_document_distribution_changes"></a>Document distribution changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Indices created with version <code class="literal">7.0.0</code> onwards will have an automatic <code class="literal">index.number_of_routing_shards</code>
value set. This might change how documents are distributed across shards depending on how many
shards the index has. In order to maintain the exact same distribution as a pre <code class="literal">7.0.0</code> index, the
<code class="literal">index.number_of_routing_shards</code> must be set to the <code class="literal">index.number_of_shards</code> at index creation time.
Note: if the number of routing shards equals the number of shards <code class="literal">_split</code> operations are not supported.</p>
<h4>
<a id="_skipped_background_refresh_on_search_idle_shards"></a>Skipped background refresh on search idle shards<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Shards belonging to an index that does not have an explicit
<code class="literal">index.refresh_interval</code> configured will  no longer refresh in the background
once the shard becomes "search idle", ie the shard hasn’t seen any search
traffic for <code class="literal">index.search.idle.after</code> seconds (defaults to <code class="literal">30s</code>). Searches
that access a search idle shard will be "parked" until the next refresh
happens.  Indexing requests with <code class="literal">wait_for_refresh</code> will also trigger
a background refresh.</p>
<h4>
<a id="_remove_deprecated_url_parameters_for_clear_indices_cache_api"></a>Remove deprecated url parameters for Clear Indices Cache API<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>The following previously deprecated url parameter have been removed:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">filter</code> - use <code class="literal">query</code> instead
</li>
<li class="listitem">
<code class="literal">filter_cache</code> - use <code class="literal">query</code> instead
</li>
<li class="listitem">
<code class="literal">request_cache</code> - use <code class="literal">request</code> instead
</li>
<li class="listitem">
<code class="literal">field_data</code> - use <code class="literal">fielddata</code> instead
</li>
</ul>
</div>
<h4>
<a id="network-breaker-inflight-requests-overhead-increased-to-2"></a><code class="literal">network.breaker.inflight_requests.overhead</code> increased to 2<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Previously the in flight requests circuit breaker considered only the raw byte representation.
By bumping the value of <code class="literal">network.breaker.inflight_requests.overhead</code> from 1 to 2, this circuit
breaker considers now also the memory overhead of representing the request as a structured object.</p>
<h4>
<a id="_parent_circuit_breaker_changes"></a>Parent circuit breaker changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>The parent circuit breaker defines a new setting <code class="literal">indices.breaker.total.use_real_memory</code> which is
<code class="literal">true</code> by default. This means that the parent circuit breaker will trip based on currently used
heap memory instead of only considering the reserved memory by child circuit breakers. When this
setting is <code class="literal">true</code>, the default parent breaker limit also changes from 70% to 95% of the JVM heap size.
The previous behavior can be restored by setting <code class="literal">indices.breaker.total.use_real_memory</code> to <code class="literal">false</code>.</p>
<h4>
<a id="_field_data_circuit_breaker_changes"></a>Field data circuit breaker changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>As doc values have been enabled by default in earlier versions of Elasticsearch,
there is less need for fielddata. Therefore, the default value of the setting
<code class="literal">indices.breaker.fielddata.limit</code> has been lowered from 60% to 40% of the JVM
heap size.</p>
<h4>
<a id="fix-value-for-index-shard-check-on-startup-removed"></a><code class="literal">fix</code> value for <code class="literal">index.shard.check_on_startup</code> is removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Deprecated option value <code class="literal">fix</code> for setting <code class="literal">index.shard.check_on_startup</code> is not supported.</p>
<h4>
<a id="elasticsearch-translog-removed"></a><code class="literal">elasticsearch-translog</code> is removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/indices.asciidoc">edit</a>
</h4>
<p>Use the <code class="literal">elasticsearch-shard</code> tool to remove corrupted translog data.</p>
<h3>
<a id="breaking_70_mappings_changes"></a>Mapping changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h3>
<h4>
<a id="all-meta-field-removed"></a>The <code class="literal">_all</code> meta field is removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The <code class="literal">_all</code> field deprecated in 6 have now been removed.</p>
<h4>
<a id="uid-meta-field-removed"></a>The <code class="literal">_uid</code> meta field is removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>This field used to index a composite key formed of the <code class="literal">_type</code> and the <code class="literal">_id</code>.
Now that indices cannot have multiple types, this has been removed in favour
of <code class="literal">_id</code>.</p>
<h4>
<a id="default-mapping-not-allowed"></a>The <code class="literal">_default_</code> mapping is no longer allowed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The <code class="literal">_default_</code> mapping has been deprecated in 6.0 and is now no longer allowed
in 7.0. Trying to configure a <code class="literal">_default_</code> mapping on 7.x indices will result in
an error.</p>
<p>If an index template contains a <code class="literal">_default_</code> mapping, it will fail to create new
indices. To resolve this issue, the <code class="literal">_default_</code> mapping should be removed from
the template. Note that in 7.x, the <a class="xref" href="indices-get-template.html" title="Get index template API">get template API</a>
does not show the <code class="literal">_default_</code> mapping by default, even when it is defined in
the mapping. To see all mappings in the template, the <code class="literal">include_type_name</code>
parameter must be supplied:</p>
<pre class="screen">GET /_template/my_template?include_type_name</pre>
<p>For more details on the <code class="literal">include_type_name</code> parameter and other types-related
API changes, please see <a class="xref" href="removal-of-types.html" title="Removal of mapping types"><em>Removal of mapping types</em></a>.</p>
<h4>
<a id="index-options-numeric-fields-removed"></a><code class="literal">index_options</code> for numeric fields has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The <code class="literal">index_options</code> field for numeric  fields has been deprecated in 6 and has now been removed.</p>
<h4>
<a id="limit-number-nested-json-objects"></a>Limiting the number of <code class="literal">nested</code> json objects<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>To safeguard against out of memory errors, the number of nested json objects within a single
document across all fields has been limited to 10000. This default limit can be changed with
the index setting <code class="literal">index.mapping.nested_objects.limit</code>.</p>
<h4>
<a id="update-all-types-option-removed"></a>The <code class="literal">update_all_types</code> option has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>This option is useless now that all indices have at most one type.</p>
<h4>
<a id="classic-similarity-removed"></a>The <code class="literal">classic</code> similarity has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The <code class="literal">classic</code> similarity relied on coordination factors for scoring to be good
in presence of stopwords in the query. This feature has been removed from
Lucene, which means that the <code class="literal">classic</code> similarity now produces scores of lower
quality. It is advised to switch to <code class="literal">BM25</code> instead, which is widely accepted
as a better alternative.</p>
<h4>
<a id="_similarities_fail_when_unsupported_options_are_provided"></a>Similarities fail when unsupported options are provided<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>An error will now be thrown when unknown configuration options are provided
to similarities. Such unknown parameters were ignored before.</p>
<h4>
<a id="changed-default-geo-shape-index-strategy"></a>Changed default <code class="literal">geo_shape</code> indexing strategy<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p><code class="literal">geo_shape</code> types now default to using a vector indexing approach based on Lucene’s new
<code class="literal">LatLonShape</code> field type. This indexes shapes as a triangular mesh instead of decomposing
them into individual grid cells. To index using legacy prefix trees the <code class="literal">tree</code> parameter
must be explicitly set to one of <code class="literal">quadtree</code> or <code class="literal">geohash</code>. Note that these strategies are
now deprecated and will be removed in a future version.</p>
<p>IMPORTANT NOTE: If using timed index creation from templates, the <code class="literal">geo_shape</code> mapping
should also be changed in the template to explicitly define <code class="literal">tree</code> to one of <code class="literal">geohash</code>
or <code class="literal">quadtree</code>. This will ensure compatibility with previously created indexes.</p>
<h4>
<a id="deprecated-geo-shape-params"></a>Deprecated <code class="literal">geo_shape</code> parameters<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The following type parameters are deprecated for the <code class="literal">geo_shape</code> field type: <code class="literal">tree</code>,
<code class="literal">precision</code>, <code class="literal">tree_levels</code>, <code class="literal">distance_error_pct</code>, <code class="literal">points_only</code>, and <code class="literal">strategy</code>. They
will be removed in a future version.</p>
<h4>
<a id="_limiting_the_number_of_completion_contexts"></a>Limiting the number of completion contexts<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The maximum allowed number of completion contexts in a mapping will be limited
to 10 in the next major version. Completion fields that define more than 10
contexts in a mapping will log a deprecation warning in this version.</p>
<h4>
<a id="include-type-name-defaults-false"></a><code class="literal">include_type_name</code> now defaults to <code class="literal">false</code><a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/mappings.asciidoc">edit</a>
</h4>
<p>The default for <code class="literal">include_type_name</code> is now <code class="literal">false</code> for all APIs that accept
the parameter.</p>
<h3>
<a id="breaking_70_ml_changes"></a>ML changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/ml.asciidoc">edit</a>
</h3>
<h4>
<a id="_types_in_datafeed_config_are_no_longer_valid"></a>Types in Datafeed config are no longer valid<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/ml.asciidoc">edit</a>
</h4>
<p>Types have been removed from the datafeed config and are no longer
valid parameters.</p>
<h3>
<a id="breaking_70_search_changes"></a>Search and Query DSL changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h3>
<h4>
<a id="_off_heap_terms_index"></a>Off-heap terms index<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The terms dictionary is the part of the inverted index that records all terms
that occur within a segment in sorted order. In order to provide fast retrieval,
terms dictionaries come with a small terms index that allows for efficient
random access by term. Until now this terms index had always been loaded
on-heap.</p>
<p>As of 7.0, the terms index is loaded on-heap for fields that only have unique
values such as <code class="literal">_id</code> fields, and off-heap otherwise - likely most other fields.
This is expected to reduce memory requirements but might slow down search
requests if both below conditions are met:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The size of the data directory on each node is significantly larger than the
amount of memory that is available to the filesystem cache.
</li>
<li class="listitem">
The number of matches of the query is not several orders of magnitude greater
than the number of terms that the query tries to match, either explicitly via
<code class="literal">term</code> or <code class="literal">terms</code> queries, or implicitly via multi-term queries such as
<code class="literal">prefix</code>, <code class="literal">wildcard</code> or <code class="literal">fuzzy</code> queries.
</li>
</ul>
</div>
<p>This change affects both existing indices created with Elasticsearch 6.x and new
indices created with Elasticsearch 7.x.</p>
<h4>
<a id="_changes_to_queries"></a>Changes to queries<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The default value for <code class="literal">transpositions</code> parameter of <code class="literal">fuzzy</code> query
has been changed to <code class="literal">true</code>.
</li>
<li class="listitem">
The <code class="literal">query_string</code> options <code class="literal">use_dismax</code>, <code class="literal">split_on_whitespace</code>,
<code class="literal">all_fields</code>, <code class="literal">locale</code>, <code class="literal">auto_generate_phrase_query</code> and
<code class="literal">lowercase_expanded_terms</code> deprecated in 6.x have been removed.
</li>
<li class="listitem">
Purely negative queries (only MUST_NOT clauses) now return a score of <code class="literal">0</code>
rather than <code class="literal">1</code>.
</li>
<li class="listitem">
The boundary specified using geohashes in the <code class="literal">geo_bounding_box</code> query
now include entire geohash cell, instead of just geohash center.
</li>
<li class="listitem">
Attempts to generate multi-term phrase queries against non-text fields
with a custom analyzer will now throw an exception.
</li>
<li class="listitem">
An <code class="literal">envelope</code> crossing the dateline in a `geo_shape `query is now processed
correctly when specified using REST API instead of having its left and
right corners flipped.
</li>
<li class="listitem">
Attempts to set <code class="literal">boost</code> on inner span queries will now throw a parsing exception.
</li>
</ul>
</div>
<h4>
<a id="_adaptive_replica_selection_enabled_by_default"></a>Adaptive replica selection enabled by default<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Adaptive replica selection has been enabled by default. If you wish to return to
the older round robin of search requests, you can use the
<code class="literal">cluster.routing.use_adaptive_replica_selection</code> setting:</p>
<div class="pre_wrapper lang-console">
<pre class="programlisting prettyprint lang-console">PUT /_cluster/settings
{
    "transient": {
        "cluster.routing.use_adaptive_replica_selection": false
    }
}</pre>
</div>
<div class="console_widget" data-snippet="snippets/2188.console"></div>
<h4>
<a id="search-api-returns-400-invalid-requests"></a>Search API returns <code class="literal">400</code> for invalid requests<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The Search API returns <code class="literal">400 - Bad request</code> while it would previously return
<code class="literal">500 - Internal Server Error</code> in the following cases of invalid request:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
the result window is too large
</li>
<li class="listitem">
sort is used in  combination with rescore
</li>
<li class="listitem">
the rescore window is too large
</li>
<li class="listitem">
the number of slices is too large
</li>
<li class="listitem">
keep alive for scroll is too large
</li>
<li class="listitem">
number of filters in the adjacency matrix aggregation is too large
</li>
<li class="listitem">
script compilation errors
</li>
</ul>
</div>
<h4>
<a id="scroll-queries-cannot-use-request-cache"></a>Scroll queries cannot use the <code class="literal">request_cache</code> anymore<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Setting <code class="literal">request_cache:true</code> on a query that creates a scroll (<code class="literal">scroll=1m</code>)
has been deprecated in 6 and will now return a <code class="literal">400 - Bad request</code>.
Scroll queries are not meant to be cached.</p>
<h4>
<a id="scroll-queries-cannot-use-rescore"></a>Scroll queries cannot use <code class="literal">rescore</code>  anymore<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Including a rescore clause on a query that creates a scroll (<code class="literal">scroll=1m</code>) has
been deprecated in 6.5 and will now return a <code class="literal">400 - Bad request</code>.  Allowing
rescore on scroll queries would break the scroll sort.  In the 6.x line, the
rescore clause was silently ignored (for scroll queries), and it was allowed in
the 5.x line.</p>
<h4>
<a id="_term_suggesters_supported_distance_algorithms"></a>Term Suggesters supported distance algorithms<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The following string distance algorithms were given additional names in 6.2 and
their existing names were deprecated. The deprecated names have now been
removed.</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">levenstein</code> - replaced by <code class="literal">levenshtein</code>
</li>
<li class="listitem">
<code class="literal">jarowinkler</code> - replaced by <code class="literal">jaro_winkler</code>
</li>
</ul>
</div>
<h4>
<a id="popular-mode-suggesters"></a><code class="literal">popular</code> mode for Suggesters<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The <code class="literal">popular</code> mode for Suggesters (<code class="literal">term</code> and <code class="literal">phrase</code>) now uses the doc frequency
(instead of the sum of the doc frequency) of the input terms to compute the frequency
threshold for candidate suggestions.</p>
<h4>
<a id="_limiting_the_number_of_terms_that_can_be_used_in_a_terms_query_request"></a>Limiting the number of terms that can be used in a Terms Query request<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Executing a Terms Query with a lot of terms may degrade the cluster performance,
as each additional term demands extra processing and memory.
To safeguard against this, the maximum number of terms that can be used in a
Terms Query request has been limited to 65536. This default maximum can be changed
for a particular index with the index setting <code class="literal">index.max_terms_count</code>.</p>
<h4>
<a id="_limiting_the_length_of_regex_that_can_be_used_in_a_regexp_query_request"></a>Limiting the length of regex that can be used in a Regexp Query request<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Executing a Regexp Query with a long regex string may degrade search performance.
To safeguard against this, the maximum length of regex that can be used in a
Regexp Query request has been limited to 1000. This default maximum can be changed
for a particular index with the index setting <code class="literal">index.max_regex_length</code>.</p>
<h4>
<a id="_limiting_the_number_of_auto_expanded_fields"></a>Limiting the number of auto-expanded fields<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Executing queries that use automatic expansion of fields (e.g. <code class="literal">query_string</code>, <code class="literal">simple_query_string</code>
or <code class="literal">multi_match</code>) can have performance issues for indices with a large numbers of fields.
To safeguard against this, a default limit of 1024 fields has been introduced for
queries using the "all fields" mode (<code class="literal">"default_field": "*"</code>) or other fieldname
expansions (e.g. <code class="literal">"foo*"</code>). If needed, you can change this limit using the
<a class="xref" href="search-settings.html#indices-query-bool-max-clause-count"><code class="literal">indices.query.bool.max_clause_count</code></a>
static cluster setting.</p>
<h4>
<a id="invalid-search-request-body"></a>Invalid <code class="literal">_search</code> request body<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Search requests with extra content after the main object will no longer be accepted
by the <code class="literal">_search</code> endpoint. A parsing exception will be thrown instead.</p>
<h4>
<a id="_doc_value_fields_default_format"></a>Doc-value fields default format<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The format of doc-value fields is changing to be the same as what could be
obtained in 6.x with the special <code class="literal">use_field_mapping</code> format. This is mostly a
change for date fields, which are now formatted based on the format that is
configured in the mappings by default. This behavior can be changed by
specifying a <a class="xref" href="search-request-body.html#request-body-search-docvalue-fields" title="Doc value fields"><code class="literal">format</code></a> within the doc-value
field.</p>
<h4>
<a id="_context_completion_suggester"></a>Context Completion Suggester<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The ability to query and index context enabled suggestions without context,
deprecated in 6.x, has been removed. Context enabled suggestion queries
without contexts have to visit every suggestion, which degrades the search performance
considerably.</p>
<p>For geo context the value of the <code class="literal">path</code> parameter is now validated against the mapping,
and the context is only accepted if <code class="literal">path</code> points to a field with <code class="literal">geo_point</code> type.</p>
<h4>
<a id="semantics-changed-max-concurrent-shared-requests"></a>Semantics changed for <code class="literal">max_concurrent_shard_requests</code><a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p><code class="literal">max_concurrent_shard_requests</code> used to limit the total number of concurrent shard
requests a single high level search request can execute. In 7.0 this changed to be the
max number of concurrent shard requests per node. The default is now <code class="literal">5</code>.</p>
<h4>
<a id="max-score-set-to-null-when-untracked"></a><code class="literal">max_score</code> set to <code class="literal">null</code> when scores are not tracked<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p><code class="literal">max_score</code> used to be set to <code class="literal">0</code> whenever scores are not tracked. <code class="literal">null</code> is now used
instead which is a more appropriate value for a scenario where scores are not available.</p>
<h4>
<a id="_negative_boosts_are_not_allowed"></a>Negative boosts are not allowed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Setting a negative <code class="literal">boost</code> for a query or a field, deprecated in 6x, is not allowed in this version.
To deboost a specific query or field you can use a <code class="literal">boost</code> comprise between 0 and 1.</p>
<h4>
<a id="_negative_scores_are_not_allowed_in_function_score_query"></a>Negative scores are not allowed in Function Score Query<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Negative scores in the Function Score Query are deprecated in 6.x, and are
not allowed in this version. If a negative score is produced as a result
of computation (e.g. in <code class="literal">script_score</code> or <code class="literal">field_value_factor</code> functions),
an error will be thrown.</p>
<h4>
<a id="_the_filter_context_has_been_removed"></a>The filter context has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The <code class="literal">filter</code> context has been removed from Elasticsearch’s query builders,
the distinction between queries and filters is now decided in Lucene depending
on whether queries need to access score or not. As a result <code class="literal">bool</code> queries with
<code class="literal">should</code> clauses that don’t need to access the score will no longer set their
<code class="literal">minimum_should_match</code> to 1. This behavior has been deprecated in the previous
major version.</p>
<h4>
<a id="hits-total-now-object-search-response"></a><code class="literal">hits.total</code> is now an object in the search response<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The total hits that match the search request is now returned as an object
with a <code class="literal">value</code> and a <code class="literal">relation</code>. <code class="literal">value</code> indicates the number of hits that
match and <code class="literal">relation</code> indicates whether the value is accurate (<code class="literal">eq</code>) or a lower bound
(<code class="literal">gte</code>):</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">{
    "hits": {
        "total": {
            "value": 1000,
            "relation": "eq"
        },
        ...
    }
}</pre>
</div>
<p>The <code class="literal">total</code> object in the response indicates that the query matches exactly 1000
documents ("eq"). The <code class="literal">value</code> is always accurate (<code class="literal">"relation": "eq"</code>) when
<code class="literal">track_total_hits</code> is set to true in the request.
You can also retrieve <code class="literal">hits.total</code> as a number in the rest response by adding
<code class="literal">rest_total_hits_as_int=true</code> in the request parameter of the search request.
This parameter has been added to ease the transition to the new format and
will be removed in the next major version (8.0).</p>
<h4>
<a id="hits-total-omitted-if-disabled"></a><code class="literal">hits.total</code> is omitted in the response if <code class="literal">track_total_hits</code> is disabled (false)<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>If <code class="literal">track_total_hits</code> is set to <code class="literal">false</code> in the search request the search response
will set <code class="literal">hits.total</code> to null and the object will not be displayed in the rest
layer. You can add <code class="literal">rest_total_hits_as_int=true</code> in the search request parameters
to get the old format back (<code class="literal">"total": -1</code>).</p>
<h4>
<a id="track-total-hits-10000-default"></a><code class="literal">track_total_hits</code> defaults to 10,000<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>By default search request will count the total hits accurately up to <code class="literal">10,000</code>
documents. If the total number of hits that match the query is greater than this
 value, the response will indicate that the returned value is a lower bound:</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">{
     "_shards": ...
     "timed_out": false,
     "took": 100,
     "hits": {
         "max_score": 1.0,
         "total" : {
             "value": 10000,    <a id="CO672-1"></a><i class="conum" data-value="1"></i>
             "relation": "gte"  <a id="CO672-2"></a><i class="conum" data-value="2"></i>
         },
         "hits": ...
     }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO672-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>There are at least 10000 documents that match the query</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO672-2"><i class="conum" data-value="2"></i></a></p>
</td>
<td align="left" valign="top">
<p>This is a lower bound (<code class="literal">"gte"</code>).</p>
</td>
</tr>
</table>
</div>
<p>You can force the count to always be accurate by setting <code class="literal">track_total_hits</code>
to true explicitly in the search request.</p>
<h4>
<a id="_limitations_on_similarities"></a>Limitations on Similarities<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Lucene 8 introduced more constraints on similarities, in particular:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
scores must not be negative,
</li>
<li class="listitem">
scores must not decrease when term freq increases,
</li>
<li class="listitem">
scores must not increase when norm (interpreted as an unsigned long) increases.
</li>
</ul>
</div>
<h4>
<a id="_weights_in_function_score_must_be_positive"></a>Weights in Function Score must be positive<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>Negative <code class="literal">weight</code> parameters in the <code class="literal">function_score</code> are no longer allowed.</p>
<h4>
<a id="_query_string_and_simple_query_string_limit_expansion_of_fields_to_1024"></a>Query string and Simple query string limit expansion of fields to 1024<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/search.asciidoc">edit</a>
</h4>
<p>The number of automatically expanded fields for the "all fields"
mode (<code class="literal">"default_field": "*"</code>) for the query_string and simple_query_string
queries is now 1024 fields.</p>
<h3>
<a id="breaking_70_suggesters_changes"></a>Suggesters changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/suggesters.asciidoc">edit</a>
</h3>
<h4>
<a id="_registration_of_suggesters_in_plugins_has_changed"></a>Registration of suggesters in plugins has changed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/suggesters.asciidoc">edit</a>
</h4>
<p>Plugins must now explicitly indicate the type of suggestion that they produce.</p>
<h4>
<a id="_phrase_suggester_now_multiples_alpha"></a>Phrase suggester now multiples alpha<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/suggesters.asciidoc">edit</a>
</h4>
<p>Previously, the laplace smoothing used by the phrase suggester added <code class="literal">alpha</code>,
when it should instead multiply.  This behavior has been changed and will
affect suggester scores.</p>
<h3>
<a id="breaking_70_packaging_changes"></a>Packaging changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/packaging.asciidoc">edit</a>
</h3>
<h4>
<a id="systemd-service-file-config"></a>systemd service file is no longer configuration<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/packaging.asciidoc">edit</a>
</h4>
<p>The systemd service file <code class="literal">/usr/lib/systemd/system/elasticsearch.service</code>
was previously marked as a configuration file in rpm and deb packages.
Overrides to the systemd elasticsearch service should be made
in <code class="literal">/etc/systemd/system/elasticsearch.service.d/override.conf</code>.</p>
<h4>
<a id="_tar_package_no_longer_includes_windows_specific_files"></a>tar package no longer includes windows specific files<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/packaging.asciidoc">edit</a>
</h4>
<p>The tar package previously included files in the <code class="literal">bin</code> directory meant only
for windows. These files have been removed. Use the <code class="literal">zip</code> package instead.</p>
<h4>
<a id="_ubuntu_14_04_is_no_longer_supported"></a>Ubuntu 14.04 is no longer supported<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/packaging.asciidoc">edit</a>
</h4>
<p>Ubuntu 14.04 will reach end-of-life on April 30, 2019. As such, we are no longer
supporting Ubuntu 14.04.</p>
<h4>
<a id="_cli_secret_prompting_is_no_longer_supported"></a>CLI secret prompting is no longer supported<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/packaging.asciidoc">edit</a>
</h4>
<p>The ability to use <code class="literal">${prompt.secret}</code> and <code class="literal">${prompt.text}</code> to collect secrets
from the CLI at server start is no longer supported.  Secure settings have replaced
the need for these prompts.</p>
<h3>
<a id="breaking_70_plugins_changes"></a>Plugins changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h3>
<h4>
<a id="_azure_repository_plugin"></a>Azure Repository plugin<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The legacy azure settings which where starting with <code class="literal">cloud.azure.storage.</code> prefix have been removed.
This includes <code class="literal">account</code>, <code class="literal">key</code>, <code class="literal">default</code> and <code class="literal">timeout</code>.
You need to use settings which are starting with <code class="literal">azure.client.</code> prefix instead.
</li>
<li class="listitem">
Global timeout setting <code class="literal">cloud.azure.storage.timeout</code> has been removed.
You must set it per azure client instead. Like <code class="literal">azure.client.default.timeout: 10s</code> for example.
</li>
</ul>
</div>
<p>See <a href="https://www.elastic.co/guide/en/elasticsearch/plugins/7.7/repository-azure-repository-settings.html#repository-azure-repository-settings" class="ulink" target="_top">Azure Repository settings</a>.</p>
<h4>
<a id="_google_cloud_storage_repository_plugin"></a>Google Cloud Storage Repository plugin<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The repository settings <code class="literal">application_name</code>, <code class="literal">connect_timeout</code> and <code class="literal">read_timeout</code> have been removed and
must now be specified in the client settings instead.
</li>
</ul>
</div>
<p>See <a href="https://www.elastic.co/guide/en/elasticsearch/plugins/7.7/repository-gcs-client.html#repository-gcs-client" class="ulink" target="_top">Google Cloud Storage Client Settings</a>.</p>
<h4>
<a id="_s3_repository_plugin"></a>S3 Repository Plugin<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The plugin now uses the path style access pattern for all requests.
In previous versions it was automatically determining whether to use virtual hosted style or path style
access.
</li>
</ul>
</div>
<h4>
<a id="_analysis_plugin_changes"></a>Analysis Plugin changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The misspelled helper method <code class="literal">requriesAnalysisSettings(AnalyzerProvider&lt;T&gt; provider)</code> has been
renamed to <code class="literal">requiresAnalysisSettings</code>
</li>
</ul>
</div>
<h4>
<a id="_file_based_discovery_plugin"></a>File-based discovery plugin<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
This plugin has been removed since its functionality is now part of
Elasticsearch and requires no plugin. The location of the hosts file has moved
from <code class="literal">$ES_PATH_CONF/file-discovery/unicast_hosts.txt</code> to
<code class="literal">$ES_PATH_CONF/unicast_hosts.txt</code>. See <a class="xref" href="modules-discovery-hosts-providers.html#file-based-hosts-provider" title="File-based seed hosts provider">the
file-based hosts provider documentation</a> for further information.
</li>
</ul>
</div>
<h4>
<a id="_security_extensions"></a>Security Extensions<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<p>As a consequence of the <a class="xref" href="breaking-changes-7.0.html#include-realm-type-in-setting" title="Security realms settings">change to Realm settings</a>,
the <code class="literal">getRealmSettings</code> method has been removed from the <code class="literal">SecurityExtension</code> class,
and the <code class="literal">settings</code> method on <code class="literal">RealmConfig</code> now returns the node’s (global) settings.
Custom security extensions should register their settings by implementing the standard
<code class="literal">Plugin.getSettings</code> method, and can retrieve them from <code class="literal">RealmConfig.settings()</code> or
using one of the <code class="literal">RealmConfig.getSetting</code> methods.
Each realm setting should be defined as an <code class="literal">AffixSetting</code> as shown in the example below:</p>
<div class="pre_wrapper lang-java">
<pre class="programlisting prettyprint lang-java">Setting.AffixSetting&lt;String&gt; MY_SETTING = Setting.affixKeySetting(
  "xpack.security.authc.realms." + MY_REALM_TYPE + ".", "my_setting",
  key -&gt; Setting.simpleString(key, properties)
);</pre>
</div>
<p>The <code class="literal">RealmSettings.simpleString</code> method can be used as a convenience for the above.</p>
<h4>
<a id="_tribe_node_removed"></a>Tribe node removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<p>Tribe node functionality has been removed in favor of
<a class="xref" href="modules-cross-cluster-search.html" title="Search across clusters">Cross Cluster Search</a>.</p>
<h4>
<a id="_discovery_implementations_are_no_longer_pluggable"></a>Discovery implementations are no longer pluggable<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The method <code class="literal">DiscoveryPlugin#getDiscoveryTypes()</code> was removed, so that plugins
can no longer provide their own discovery implementations.
</li>
</ul>
</div>
<h4>
<a id="watcher-hipchat-action-removed"></a>Watcher <em>hipchat</em> action removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/plugins.asciidoc">edit</a>
</h4>
<p>Hipchat has been deprecated and shut down as a service. The <code class="literal">hipchat</code> action for
watches has been removed.</p>
<h3>
<a id="breaking_70_api_changes"></a>API changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h3>
<h4>
<a id="_internal_versioning_is_no_longer_supported_for_optimistic_concurrency_control"></a>Internal Versioning is no longer supported for optimistic concurrency control<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>Elasticsearch maintains a numeric version field for each document it stores. That field
is incremented by one with every change to the document. Until 7.0.0 the API allowed using
that field for optimistic concurrency control, i.e., making a write operation conditional
on the current document version. Sadly, that approach is flawed because the value of the
version doesn’t always uniquely represent a change to the document. If a primary fails
while handling a write operation, it may expose a version that will then be reused by the
new primary.</p>
<p>Due to that issue, internal versioning can no longer be used and is replaced by a new
method based on sequence numbers. See <a class="xref" href="optimistic-concurrency-control.html" title="Optimistic concurrency control">Optimistic concurrency control</a> for more details.</p>
<p>Note that the <code class="literal">external</code> versioning type is still fully supported.</p>
<h4>
<a id="_camel_case_and_underscore_parameters_deprecated_in_6_x_have_been_removed"></a>Camel case and underscore parameters deprecated in 6.x have been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>A number of duplicate parameters deprecated in 6.x have been removed from
Bulk request, Multi Get request, Term Vectors request, and More Like This Query
requests.</p>
<p>The following camel case parameters have been removed:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">opType</code>
</li>
<li class="listitem">
<code class="literal">versionType</code>, <code class="literal">_versionType</code>
</li>
</ul>
</div>
<p>The following parameters starting with underscore have been removed:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">_parent</code>
</li>
<li class="listitem">
<code class="literal">_retry_on_conflict</code>
</li>
<li class="listitem">
<code class="literal">_routing</code>
</li>
<li class="listitem">
<code class="literal">_version</code>
</li>
<li class="listitem">
<code class="literal">_version_type</code>
</li>
</ul>
</div>
<p>Instead of these removed parameters, use their non camel case equivalents without
starting underscore, e.g. use <code class="literal">version_type</code> instead of <code class="literal">_version_type</code> or <code class="literal">versionType</code>.</p>
<h4>
<a id="_thread_pool_info"></a>Thread pool info<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>In previous versions of Elasticsearch, the thread pool info returned in the
<a class="xref" href="cluster-nodes-info.html" title="Nodes info API">nodes info API</a> returned <code class="literal">min</code> and <code class="literal">max</code> values reflecting
the configured minimum and maximum number of threads that could be in each
thread pool. The trouble with this representation is that it does not align with
the configuration parameters used to configure thread pools. For
<a class="xref" href="modules-threadpool.html" title="Thread pools">scaling thread pools</a>, the minimum number of threads is
configured by a parameter called <code class="literal">core</code> and the maximum number of threads is
configured by a parameter called <code class="literal">max</code>. For <a class="xref" href="modules-threadpool.html" title="Thread pools">fixed thread
pools</a>, there is only one configuration parameter along these lines and that
parameter is called <code class="literal">size</code>, reflecting the fixed number of threads in the
pool. This discrepancy between the API and the configuration parameters has been
rectified. Now, the API will report <code class="literal">core</code> and <code class="literal">max</code> for scaling thread pools,
and <code class="literal">size</code> for fixed thread pools.</p>
<p>Similarly, in the cat thread pool API the existing <code class="literal">size</code> output has been
renamed to <code class="literal">pool_size</code> which reflects the number of threads currently in the
pool; the shortcut for this value has been changed from <code class="literal">s</code> to <code class="literal">psz</code>.  The <code class="literal">min</code>
output has been renamed to <code class="literal">core</code> with a shortcut of <code class="literal">cr</code>, the shortcut for
<code class="literal">max</code> has been changed to <code class="literal">mx</code>, and the <code class="literal">size</code> output with a shortcut of <code class="literal">sz</code>
has been reused to report the configured number of threads in the pool.  This
aligns the output of the API with the configuration values for thread
pools. Note that <code class="literal">core</code> and <code class="literal">max</code> will be populated for scaling thread pools,
and <code class="literal">size</code> will be populated for fixed thread pools.</p>
<h4>
<a id="fields-param-removed-bulk-update-request"></a>The parameter <code class="literal">fields</code> deprecated in 6.x has been removed from Bulk request<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>and Update request. The Update API returns <code class="literal">400 - Bad request</code> if request contains
unknown parameters (instead of ignored in the previous version).</p>
<h4>
<a id="_put_document_with_version_error_message_changed_when_document_is_missing"></a>PUT Document with Version error message changed when document is missing<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>If you attempt to <code class="literal">PUT</code> a document with versioning (e.g. <code class="literal">PUT /test/_doc/1?version=4</code>)
but the document does not exist, a cryptic message is returned:</p>
<div class="pre_wrapper lang-text">
<pre class="programlisting prettyprint lang-text">version conflict, current version [-1] is different than the one provided [4]</pre>
</div>
<p>Now if the document is missing a more helpful message is returned:</p>
<div class="pre_wrapper lang-text">
<pre class="programlisting prettyprint lang-text">document does not exist (expected version [4])</pre>
</div>
<p>Although exceptions messages are liable to change and not generally subject to
backwards compatibility, the nature of this message might mean clients are relying
on parsing the version numbers and so the format change might impact some users.</p>
<h4>
<a id="remove-suggest-metric"></a>Remove support for <code class="literal">suggest</code> metric/index metric in indices stats and nodes stats APIs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>Previously, <code class="literal">suggest</code> stats were folded into <code class="literal">search</code> stats. Support for the
<code class="literal">suggest</code> metric on the indices stats and nodes stats APIs remained for
backwards compatibility. Backwards support for the <code class="literal">suggest</code> metric was
deprecated in 6.3.0 and now removed in 7.0.0.</p>
<p><a id="remove-field-caps-body"></a>In the past, <code class="literal">fields</code> could be provided either as a parameter, or as part of the request
body. Specifying <code class="literal">fields</code> in the request body as opposed to a parameter was deprecated
in 6.4.0, and is now unsupported in 7.0.0.</p>
<h4>
<a id="copy-settings-deprecated-shrink-split-apis"></a><code class="literal">copy_settings</code> is deprecated on shrink and split APIs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>Versions of Elasticsearch prior to 6.4.0 did not copy index settings on shrink
and split operations. Starting with Elasticsearch 7.0.0, the default behavior
will be for such settings to be copied on such operations. To enable users in
6.4.0 to transition in 6.4.0 to the default behavior in 7.0.0, the
<code class="literal">copy_settings</code> parameter was added on the REST layer. As this behavior will be
the only behavior in 8.0.0, this parameter is deprecated in 7.0.0 for removal in
8.0.0.</p>
<h4>
<a id="_the_deprecated_stored_script_contexts_have_now_been_removed"></a>The deprecated stored script contexts have now been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>When putting stored scripts, support for storing them with the deprecated <code class="literal">template</code> context or without a context is
now removed. Scripts must be stored using the <code class="literal">script</code> context as mentioned in the documentation.</p>
<h4>
<a id="_removed_get_aliases_api_limitations_when_security_features_are_enabled"></a>Removed Get Aliases API limitations when security features are enabled<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The behavior and response codes of the get aliases API no longer vary
depending on whether security features are enabled. Previously a
404 - NOT FOUND (IndexNotFoundException) could be returned in case the
current user was not authorized for any alias. An empty response with
status 200 - OK is now returned instead at all times.</p>
<h4>
<a id="user-object-removed-put-user-api"></a>Put User API response no longer has <code class="literal">user</code> object<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The Put User API response was changed in 6.5.0 to add the <code class="literal">created</code> field
outside of the user object where it previously had been. In 7.0.0 the user
object has been removed in favor of the top level <code class="literal">created</code> field.</p>
<h4>
<a id="source-include-exclude-params-removed"></a>Source filtering url parameters <code class="literal">_source_include</code> and <code class="literal">_source_exclude</code> have been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The deprecated in 6.x url parameters are now removed. Use <code class="literal">_source_includes</code> and <code class="literal">_source_excludes</code> instead.</p>
<h4>
<a id="_multi_search_request_metadata_validation"></a>Multi Search Request metadata validation<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>MultiSearchRequests issued through <code class="literal">_msearch</code> now validate all keys in the metadata section. Previously unknown keys were ignored
while now an exception is thrown.</p>
<h4>
<a id="_deprecated_graph_endpoints_removed"></a>Deprecated graph endpoints removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The deprecated graph endpoints (those with <code class="literal">/_graph/_explore</code>) have been
removed.</p>
<h4>
<a id="deprecated-termvector-endpoint-removed"></a>Deprecated <code class="literal">_termvector</code> endpoint removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The <code class="literal">_termvector</code> endpoint was deprecated in 2.0 and has now been removed.
The endpoint <code class="literal">_termvectors</code> (plural) should be used instead.</p>
<h4>
<a id="_when_security_features_are_enabled_index_monitoring_apis_over_restricted_indices_are_not_authorized_implicitly_anymore"></a>When security features are enabled, index monitoring APIs over restricted indices are not authorized implicitly anymore<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>Restricted indices (currently only <code class="literal">.security-6</code> and <code class="literal">.security</code>) are special internal
indices that require setting the <code class="literal">allow_restricted_indices</code> flag on every index
permission that covers them. If this flag is <code class="literal">false</code> (default) the permission
will not cover these and actions against them will not be authorized.
However, the monitoring APIs were the only exception to this rule. This exception
has been forfeited and index monitoring privileges have to be granted explicitly,
using the <code class="literal">allow_restricted_indices</code> flag on the permission (as any other index
privilege).</p>
<h4>
<a id="remove-get-support-cache-clear-api"></a>Removed support for <code class="literal">GET</code> on the <code class="literal">_cache/clear</code> API<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The <code class="literal">_cache/clear</code> API no longer supports the <code class="literal">GET</code> HTTP verb. It must be called
with <code class="literal">POST</code>.</p>
<h4>
<a id="_cluster_state_size_metrics_removed_from_cluster_state_api_response"></a>Cluster state size metrics removed from Cluster State API Response<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The <code class="literal">compressed_size</code> / <code class="literal">compressed_size_in_bytes</code> fields were removed from
the Cluster State API response.  The calculation of the size was expensive and had
dubious value, so the field was removed from the response.</p>
<h4>
<a id="_migration_assistance_api_has_been_removed"></a>Migration Assistance API has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The Migration Assistance API has been functionally replaced by the
Deprecation Info API, and the Migration Upgrade API is not used for the
transition from ES 6.x to 7.x, and does not need to be kept around to
repair indices that were not properly upgraded before upgrading the
cluster, as was the case in 6.</p>
<h4>
<a id="_changes_to_thread_pool_naming_in_node_and_cat_apis"></a>Changes to thread pool naming in Node and Cat APIs<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>The <code class="literal">thread_pool</code> information returned from the Nodes and Cat APIs has been
standardized to use the same terminology as the thread pool configurations.
This means the response will align with the configuration instead of being
the same across all the thread pools, regardless of type.</p>
<h4>
<a id="_return_200_when_cluster_has_valid_read_only_blocks"></a>Return 200 when cluster has valid read-only blocks<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>If the cluster was configured with <code class="literal">no_master_block: write</code> and lost its master,
it would return a <code class="literal">503</code> status code from a main request (<code class="literal">GET /</code>) even though
there are viable read-only nodes available.  The cluster now returns 200 status
in this situation.</p>
<h4>
<a id="_clearing_indices_cache_is_now_post_only"></a>Clearing indices cache is now POST-only<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/api.asciidoc">edit</a>
</h4>
<p>Clearing the cache indices could previously be done via GET and POST. As GET should
only support read only non state-changing operations, this is no longer allowed.
Only POST can be used to clear the cache.</p>
<h3>
<a id="breaking_70_java_changes"></a>Java API changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h3>
<h4>
<a id="isshardsacked-removed"></a><code class="literal">isShardsAcked</code> deprecated in <code class="literal">6.2</code> has been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<p><code class="literal">isShardsAcked</code> has been replaced by <code class="literal">isShardsAcknowledged</code> in
<code class="literal">CreateIndexResponse</code>, <code class="literal">RolloverResponse</code> and
<code class="literal">CreateIndexClusterStateUpdateResponse</code>.</p>
<h4>
<a id="prepareexecute-removed-client-api"></a><code class="literal">prepareExecute</code> removed from the client api<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<p>The <code class="literal">prepareExecute</code> method which created a request builder has been
removed from the client api. Instead, construct a builder for the
appropriate request directly.</p>
<h4>
<a id="_some_aggregation_classes_have_moved_packages"></a>Some Aggregation classes have moved packages<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
All classes present in <code class="literal">org.elasticsearch.search.aggregations.metrics.*</code> packages
were moved to a single <code class="literal">org.elasticsearch.search.aggregations.metrics</code> package.
</li>
<li class="listitem">
All classes present in <code class="literal">org.elasticsearch.search.aggregations.pipeline.*</code> packages
were moved to a single <code class="literal">org.elasticsearch.search.aggregations.pipeline</code> package.  In
addition, <code class="literal">org.elasticsearch.search.aggregations.pipeline.PipelineAggregationBuilders</code>
was moved to <code class="literal">org.elasticsearch.search.aggregations.PipelineAggregationBuilders</code>
</li>
</ul>
</div>
<h4>
<a id="retry-withbackoff-methods-removed"></a><code class="literal">Retry.withBackoff</code> methods with <code class="literal">Settings</code> removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<p>The variants of <code class="literal">Retry.withBackoff</code> that included <code class="literal">Settings</code> have been removed
because <code class="literal">Settings</code> is no longer needed.</p>
<h4>
<a id="client-termvector-removed"></a>Deprecated method <code class="literal">Client#termVector</code> removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<p>The client method <code class="literal">termVector</code>, deprecated in 2.0, has been removed. The method
<code class="literal">termVectors</code> (plural) should be used instead.</p>
<h4>
<a id="abstractlifecyclecomponent-constructor-removed"></a>Deprecated constructor <code class="literal">AbstractLifecycleComponent(Settings settings)</code> removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<p>The constructor <code class="literal">AbstractLifecycleComponent(Settings settings)</code>, deprecated in 6.7
has been removed. The parameterless constructor should be used instead.</p>
<h4>
<a id="_changes_to_geometry_classes"></a>Changes to Geometry classes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java.asciidoc">edit</a>
</h4>
<p>Geometry classes used to represent geo values in SQL have been moved from the
<code class="literal">org.elasticsearch.geo.geometry</code> package to the <code class="literal">org.elasticsearch.geometry</code>
package and the order of the constructor parameters has changed from <code class="literal">lat</code>, <code class="literal">lon</code>
to <code class="literal">lon</code>, <code class="literal">lat</code>.</p>
<h3>
<a id="breaking_70_settings_changes"></a>Settings changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h3>
<h4>
<a id="default-node-name-now-hostname"></a>The default for <code class="literal">node.name</code> is now the hostname<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p><code class="literal">node.name</code> now defaults to the hostname at the time when Elasticsearch
is started. Previously the default node name was the first eight characters
of the node id. It can still be configured explicitly in <code class="literal">elasticsearch.yml</code>.</p>
<h4>
<a id="_percolator"></a>Percolator<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The deprecated <code class="literal">index.percolator.map_unmapped_fields_as_string</code> setting has been removed in favour of
the <code class="literal">index.percolator.map_unmapped_fields_as_text</code> setting.
</li>
</ul>
</div>
<h4>
<a id="_index_thread_pool"></a>Index thread pool<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Internally, single-document index/delete/update requests are executed as bulk
requests with a single-document payload. This means that these requests are
executed on the bulk thread pool. As such, the indexing thread pool is no
longer needed and has been removed. As such, the  settings
<code class="literal">thread_pool.index.size</code> and <code class="literal">thread_pool.index.queue_size</code> have been removed.
</li>
</ul>
</div>
<h4>
<a id="write-thread-pool-fallback"></a>Write thread pool fallback<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The bulk thread pool was replaced by the write thread pool in 6.3.0. However,
for backwards compatibility reasons the name <code class="literal">bulk</code> was still usable as fallback
settings <code class="literal">thread_pool.bulk.size</code> and <code class="literal">thread_pool.bulk.queue_size</code> for
<code class="literal">thread_pool.write.size</code> and <code class="literal">thread_pool.write.queue_size</code>, respectively, and
the system property <code class="literal">es.thread_pool.write.use_bulk_as_display_name</code> was
available to keep the display output in APIs as <code class="literal">bulk</code> instead of <code class="literal">write</code>.
These fallback settings and this system property have been removed.
</li>
</ul>
</div>
<h4>
<a id="_disabling_memory_mapping"></a>Disabling memory-mapping<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The setting <code class="literal">node.store.allow_mmapfs</code> has been renamed to <code class="literal">node.store.allow_mmap</code>.
</li>
</ul>
</div>
<h4>
<a id="remove-http-enabled"></a>Http enabled setting removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The setting <code class="literal">http.enabled</code> previously allowed disabling binding to HTTP, only allowing
use of the transport client. This setting has been removed, as the transport client
will be removed in the future, thus requiring HTTP to always be enabled.
</li>
</ul>
</div>
<h4>
<a id="remove-http-pipelining-setting"></a>Http pipelining setting removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
The setting <code class="literal">http.pipelining</code> previously allowed disabling HTTP pipelining support.
This setting has been removed, as disabling http pipelining support on the server
provided little value. The setting <code class="literal">http.pipelining.max_events</code> can still be used to
limit the number of pipelined requests in-flight.
</li>
</ul>
</div>
<h4>
<a id="_cross_cluster_search_settings_renamed"></a>Cross-cluster search settings renamed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The cross-cluster search remote cluster connection infrastructure is also used
in cross-cluster replication. This means that the setting names
<code class="literal">search.remote.*</code> used for configuring cross-cluster search belie the fact that
they also apply to other situations where a connection to a remote cluster as
used.  Therefore, these settings have been renamed from <code class="literal">search.remote.*</code> to
<code class="literal">cluster.remote.*</code>. For backwards compatibility purposes, we will fallback to
<code class="literal">search.remote.*</code> if <code class="literal">cluster.remote.*</code> is not set. For any such settings stored
in the cluster state, or set on dynamic settings updates, we will automatically
upgrade the setting from <code class="literal">search.remote.*</code> to <code class="literal">cluster.remote.*</code>. The fallback
settings will be removed in 8.0.0.</p>
<h4>
<a id="audit-logfile-local-node-info"></a>Audit logfile local node info<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The following settings have been removed:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">xpack.security.audit.logfile.prefix.emit_node_host_address</code>, instead use
<code class="literal">xpack.security.audit.logfile.emit_node_host_address</code>
</li>
<li class="listitem">
<code class="literal">xpack.security.audit.logfile.prefix.emit_node_host_name</code>, instead use
<code class="literal">xpack.security.audit.logfile.emit_node_host_name</code>
</li>
<li class="listitem">
<code class="literal">xpack.security.audit.logfile.prefix.emit_node_name</code>, instead use
<code class="literal">xpack.security.audit.logfile.emit_node_name</code>
</li>
</ul>
</div>
<p>The new settings have the same meaning as the removed ones, but the <code class="literal">prefix</code>
name component is no longer meaningful as logfile audit entries are structured
JSON documents and are not prefixed by anything.
Moreover, <code class="literal">xpack.security.audit.logfile.emit_node_name</code> has changed its default
from <code class="literal">true</code> to <code class="literal">false</code>. All other settings mentioned before, have kept their
default value of <code class="literal">false</code>.</p>
<h4>
<a id="include-realm-type-in-setting"></a>Security realms settings<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The settings for all security realms must now include the realm type as part
of the setting name, and the explicit <code class="literal">type</code> setting has been removed.</p>
<p>A realm that was previous configured as:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.authc.realms:
  ldap1:
    type: ldap
    order: 1
    url: "ldaps://ldap.example.com/"</pre>
</div>
<p>Must be migrated to:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.authc.realms:
  ldap.ldap1:
    order: 1
    url: "ldaps://ldap.example.com/"</pre>
</div>
<p>Any realm specific secure settings that have been stored in the elasticsearch
keystore (such as ldap bind passwords, or passwords for ssl keys) must be updated
in a similar way.</p>
<h4>
<a id="tls-setting-fallback"></a>TLS/SSL settings<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The default TLS/SSL settings, which were prefixed by <code class="literal">xpack.ssl</code>, have been removed.
The removal of these default settings also removes the ability for a component to
fallback to a default configuration when using TLS. Each component (realm, transport, http,
http client, etc) must now be configured with their own settings for TLS if it is being
used.</p>
<h4>
<a id="tls-v1-removed"></a>TLS v1.0 disabled<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>TLS version 1.0 is now disabled by default as it suffers from
<a href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Only_Support_Strong_Protocols" class="ulink" target="_top">known security issues</a>.
The default protocols are now TLSv1.3 (if supported), TLSv1.2 and TLSv1.1.</p>
<p>You can enable TLS v1.0 by configuring the relevant <code class="literal">ssl.supported_protocols</code>
setting to include <code class="literal">"TLSv1"</code>.
Depending on your local configuration and the TLS protocols that are in use
on your network, you may need to enable TLS v1.0 support in any or all of the
following places:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
<code class="literal">xpack.security.http.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For incoming HTTP connections to Elasticsearch’s HTTP (Rest) interface.
If there are clients that connect to Elasticsearch and do not support newer TLS versions,
you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.http.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For outgoing HTTP connections from Watcher.
If you have watches that connect to external HTTP servers and do not support
newer TLS versions, you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.security.authc.realms.ldap.{name}.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For outgoing LDAP connections from Elasticsearch security features.
If you have an LDAP realm enabled and the LDAP directory to which that realm
connects does not support newer TLS versions, you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.security.authc.realms.active_directory.{name}.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For outgoing Active Directory (LDAP) connections from Elasticsearch security features.
If you have an AD realm enabled and the directory server to which that realm
connects does not support newer TLS versions, you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.security.authc.realms.saml.{name}.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For outgoing HTTP connections to retrieve SAML metadata.
If you have a SAML realm enabled and the realm is configured to retrieve
metadata over HTTPS (that is, <code class="literal">idp.metadata.path</code> is a URL starting with
<code class="literal">https://</code>) and the web server which hosts the metadata does not support newer
TLS versions, you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.security.authc.realms.oidc.{name}.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For outgoing HTTP connections to an OpenId Connect Provider.
If you have an OpenId Connect ("oidc") realm enabled and the realm is configured
to connect to a remote OpenID Connect Provider which does not support newer TLS
versions, you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.monitoring.exporters.{name}.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For remote monitoring data.
If your monitoring data is exported to a remote monitoring cluster and that
cluster is configured to only support TLSv1, you must update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">reindex.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For reindex from remote.
If you reindex data from a remote Elasticsearch cluster which has SSL enabled on the
<code class="literal">http</code> interface and that cluster is configured to only support TLSv1, you must
update this setting.
</dd>
<dt>
<span class="term">
<code class="literal">xpack.security.transport.ssl.supported_protocols</code>
</span>
</dt>
<dd>
For incoming connections between Elasticsearch nodes. If you have specialized network
equipment which inspects TLS packets between your nodes, and that equipment
enforces TLSv1 you must update this setting.
</dd>
</dl>
</div>
<p>The following is an example that enables TLS v1.0 for incoming HTTP connections:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.security.http.ssl.supported_protocols: [ "TLSv1.3", "TLSv1.2", "TLSv1.1", "TLSv1" ]</pre>
</div>
<h4>
<a id="trial-explicit-security"></a>Security on Trial Licenses<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>On trial licenses, <code class="literal">xpack.security.enabled</code> defaults to <code class="literal">false</code>.</p>
<p>In prior versions, a trial license would automatically enable security if either</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">xpack.security.transport.enabled</code> was <code class="literal">true</code>; <em>or</em>
</li>
<li class="listitem">
the trial license was generated on a version of X-Pack from 6.2 or earlier.
</li>
</ul>
</div>
<p>This behaviour has been now removed, so security is only enabled if:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">xpack.security.enabled</code> is <code class="literal">true</code>; <em>or</em>
</li>
<li class="listitem">
<code class="literal">xpack.security.enabled</code> is not set, and a gold or platinum license is installed.
</li>
</ul>
</div>
<h4>
<a id="watcher-notifications-account-settings"></a>Watcher notifications account settings<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The following settings have been removed in favor of the secure variants.
The <a class="xref" href="secure-settings.html" title="Secure settings">secure settings</a> have to be defined inside each cluster
node’s keystore, i.e., they are not to be specified via the cluster settings API.</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">xpack.notification.email.account.&lt;id&gt;.smtp.password</code>, instead use
<code class="literal">xpack.notification.email.account.&lt;id&gt;.smtp.secure_password</code>
</li>
<li class="listitem">
<code class="literal">xpack.notification.hipchat.account.&lt;id&gt;.auth_token</code>, instead use
<code class="literal">xpack.notification.hipchat.account.&lt;id&gt;.secure_auth_token</code>
</li>
<li class="listitem">
<code class="literal">xpack.notification.jira.account.&lt;id&gt;.url</code>, instead use
<code class="literal">xpack.notification.jira.account.&lt;id&gt;.secure_url</code>
</li>
<li class="listitem">
<code class="literal">xpack.notification.jira.account.&lt;id&gt;.user</code>, instead use
<code class="literal">xpack.notification.jira.account.&lt;id&gt;.secure_user</code>
</li>
<li class="listitem">
<code class="literal">xpack.notification.jira.account.&lt;id&gt;.password</code>, instead use
<code class="literal">xpack.notification.jira.account.&lt;id&gt;.secure_password</code>
</li>
<li class="listitem">
<code class="literal">xpack.notification.pagerduty.account.&lt;id&gt;.service_api_key</code>, instead use
<code class="literal">xpack.notification.pagerduty.account.&lt;id&gt;.secure_service_api_key</code>
</li>
<li class="listitem">
<code class="literal">xpack.notification.slack.account.&lt;id&gt;.url</code>, instead use
<code class="literal">xpack.notification.slack.account.&lt;id&gt;.secure_url</code>
</li>
</ul>
</div>
<h4>
<a id="remove-audit-index-output"></a>Audit index output type removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>All the settings under the <code class="literal">xpack.security.audit.index</code> namespace have been
removed. In addition, the <code class="literal">xpack.security.audit.outputs</code> setting has been
removed as well.</p>
<p>These settings enabled and configured the audit index output type. This output
type has been removed because it was unreliable in certain scenarios and this
could have lead to dropping audit events while the operations on the system
were allowed to continue as usual. The recommended replacement is the
use of the <code class="literal">logfile</code> audit output type and using other components from the
Elastic Stack to handle the indexing part.</p>
<h4>
<a id="ingest-user-agent-ecs-always"></a>Ingest User Agent processor defaults uses <code class="literal">ecs</code> output format<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p><a href="https://github.com/elastic/ecs" class="ulink" target="_top">ECS</a> format is now the default.
The <code class="literal">ecs</code> setting for the user agent ingest processor now defaults to true.</p>
<h4>
<a id="remove-action-master-force_local"></a>Remove <code class="literal">action.master.force_local</code><a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The <code class="literal">action.master.force_local</code> setting was an undocumented setting, used
internally by the tribe node to force reads to local cluster state (instead of
forwarding to a master, which tribe nodes did not have).  Since the tribe
node was removed, this setting was removed too.</p>
<h4>
<a id="_enforce_cluster_wide_shard_limit"></a>Enforce cluster-wide shard limit<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>The cluster-wide shard limit is now enforced and not optional. The limit can
still be adjusted as desired using the cluster settings API.</p>
<h4>
<a id="_http_max_content_length_setting_is_no_longer_parsed_leniently"></a>HTTP Max content length setting is no longer parsed leniently<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/settings.asciidoc">edit</a>
</h4>
<p>Previously, <code class="literal">http.max_content_length</code> would reset to <code class="literal">100mb</code> if the setting was
greater than <code class="literal">Integer.MAX_VALUE</code>.  This leniency has been removed.</p>
<h3>
<a id="breaking_70_scripting_changes"></a>Scripting changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/scripting.asciidoc">edit</a>
</h3>
<h4>
<a id="_getdate_and_getdates_removed"></a>getDate() and getDates() removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/scripting.asciidoc">edit</a>
</h4>
<p>Fields of type <code class="literal">long</code> and <code class="literal">date</code> had <code class="literal">getDate()</code> and <code class="literal">getDates()</code> methods
(for multi valued fields) to get an object with date specific helper methods
for the current doc value. In 5.3.0, <code class="literal">date</code> fields were changed to expose
this same date object directly when calling <code class="literal">doc["myfield"].value</code>, and
the getter methods for date objects were deprecated. These methods have
now been removed. Instead, use <code class="literal">.value</code> on <code class="literal">date</code> fields, or explicitly
parse <code class="literal">long</code> fields into a date object using
<code class="literal">Instance.ofEpochMillis(doc["myfield"].value)</code>.</p>
<h4>
<a id="_accessing_missing_document_values_will_throw_an_error"></a>Accessing missing document values will throw an error<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/scripting.asciidoc">edit</a>
</h4>
<p><code class="literal">doc['field'].value</code> will throw an exception if
the document is missing a value for the field <code class="literal">field</code>.</p>
<p>To check if a document is missing a value, you can use
<code class="literal">doc['field'].size() == 0</code>.</p>
<h4>
<a id="script-errors-return-400-error-codes"></a>Script errors will return as <code class="literal">400</code> error codes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/scripting.asciidoc">edit</a>
</h4>
<p>Malformed scripts, either in search templates, ingest pipelines or search
requests, return <code class="literal">400 - Bad request</code> while they would previously return
<code class="literal">500 - Internal Server Error</code>. This also applies for stored scripts.</p>
<h4>
<a id="_getvalues_removed"></a>getValues() removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/scripting.asciidoc">edit</a>
</h4>
<p>The <code class="literal">ScriptDocValues#getValues()</code> method is deprecated in 6.6 and will
be removed in 7.0. Use <code class="literal">doc["foo"]</code> in place of <code class="literal">doc["foo"].values</code>.</p>
<h3>
<a id="breaking_70_snapshotstats_changes"></a>Snapshot stats changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/snapshotstats.asciidoc">edit</a>
</h3>
<p>Snapshot stats details are provided in a new structured way:</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">total</code> section for all the files that are referenced by the snapshot.
</li>
<li class="listitem">
<code class="literal">incremental</code> section for those files that actually needed to be copied over as part of the incremental snapshotting.
</li>
<li class="listitem">
In case of a snapshot that’s still in progress, there’s also a <code class="literal">processed</code> section for files that are in the process of being copied.
</li>
</ul>
</div>
<h4>
<a id="snapshot-stats-deprecated"></a>Deprecated <code class="literal">number_of_files</code>, <code class="literal">processed_files</code>, <code class="literal">total_size_in_bytes</code> and <code class="literal">processed_size_in_bytes</code> snapshot stats properties have been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/snapshotstats.asciidoc">edit</a>
</h4>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
Properties <code class="literal">number_of_files</code> and <code class="literal">total_size_in_bytes</code> are removed and should be replaced by values of nested object <code class="literal">total</code>.
</li>
<li class="listitem">
Properties <code class="literal">processed_files</code> and <code class="literal">processed_size_in_bytes</code> are removed and should be replaced by values of nested object <code class="literal">processed</code>.
</li>
</ul>
</div>
<h3>
<a id="breaking_70_restclient_changes"></a>High-level REST client changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/restclient.asciidoc">edit</a>
</h3>
<h4>
<a id="remove-header-args"></a>API methods accepting <code class="literal">Header</code> argument have been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/restclient.asciidoc">edit</a>
</h4>
<p>All API methods accepting headers as a <code class="literal">Header</code> varargs argument, deprecated
since 6.4, have been removed in favour of the newly introduced methods that
accept instead a <code class="literal">RequestOptions</code> argument. In case you are not specifying any
header, e.g. <code class="literal">client.index(indexRequest)</code> becomes
<code class="literal">client.index(indexRequest, RequestOptions.DEFAULT)</code>.
In case you are specifying headers
e.g. <code class="literal">client.index(indexRequest, new Header("name" "value"))</code> becomes
<code class="literal">client.index(indexRequest, RequestOptions.DEFAULT.toBuilder().addHeader("name", "value").build());</code></p>
<h4>
<a id="cluster-health-api-default-cluster-level"></a>Cluster Health API default to <code class="literal">cluster</code> level<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/restclient.asciidoc">edit</a>
</h4>
<p>The Cluster Health API used to default to <code class="literal">shards</code> level to ease migration
from transport client that doesn’t support the <code class="literal">level</code> parameter and always
returns information including indices and shards details. The level default
value has been aligned with the Elasticsearch default level: <code class="literal">cluster</code>.</p>
<h3>
<a id="breaking_70_low_level_restclient_changes"></a>Low-level REST client changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/low_level_restclient.asciidoc">edit</a>
</h3>
<h4>
<a id="maxretrytimeout-removed"></a>Support for <code class="literal">maxRetryTimeout</code> removed from RestClient<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/low_level_restclient.asciidoc">edit</a>
</h4>
<p><code class="literal">RestClient</code> and <code class="literal">RestClientBuilder</code> no longer support the <code class="literal">maxRetryTimeout</code>
setting. The setting was removed as its counting mechanism was not accurate
and caused issues while adding little value.</p>
<h4>
<a id="_deprecated_flavors_of_performrequest_have_been_removed"></a>Deprecated flavors of performRequest have been removed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/low_level_restclient.asciidoc">edit</a>
</h4>
<p>We deprecated the flavors of <code class="literal">performRequest</code> and <code class="literal">performRequestAsync</code> that
do not take <code class="literal">Request</code> objects in 6.4.0 in favor of the flavors that take
<code class="literal">Request</code> objects because those methods can be extended without breaking
backwards compatibility.</p>
<h4>
<a id="_removed_sethosts"></a>Removed setHosts<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/low_level_restclient.asciidoc">edit</a>
</h4>
<p>We deprecated <code class="literal">setHosts</code> in 6.4.0 in favor of <code class="literal">setNodes</code> because it supports
host metadata used by the <code class="literal">NodeSelector</code>.</p>
<h4>
<a id="_minimum_compiler_version_change"></a>Minimum compiler version change<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/low_level_restclient.asciidoc">edit</a>
</h4>
<p>The minimum compiler version on the low-level REST client has been bumped
to JDK 8.</p>
<h3>
<a id="breaking_70_logging_changes"></a>Logging changes<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/logging.asciidoc">edit</a>
</h3>
<h4>
<a id="new-json-format-log-directory"></a>New JSON format log files in <code class="literal">log</code> directory<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/logging.asciidoc">edit</a>
</h4>
<p>Elasticsearch now will produce additional log files in JSON format. They will be stored in <code class="literal">*.json</code> suffix files.
Following files should be expected now in log directory:
* ${cluster_name}_server.json
* ${cluster_name}_deprecation.json
* ${cluster_name}_index_search_slowlog.json
* ${cluster_name}_index_indexing_slowlog.json
* ${cluster_name}.log
* ${cluster_name}_deprecation.log
* ${cluster_name}_index_search_slowlog.log
* ${cluster_name}_index_indexing_slowlog.log
* ${cluster_name}_audit.json
* gc.log</p>
<p>Note: You can configure which of these files are written by editing <code class="literal">log4j2.properties</code>.</p>
<h4>
<a id="log-files-ending-log-deprecated"></a>Log files ending with <code class="literal">*.log</code> deprecated<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/logging.asciidoc">edit</a>
</h4>
<p>Log files with the <code class="literal">.log</code> file extension using the old pattern layout format
are now considered deprecated and the newly added JSON log file format with
the <code class="literal">.json</code> file extension should be used instead.
Note: GC logs which are written to the file <code class="literal">gc.log</code> will not be changed.</p>
<h4>
<a id="_docker_output_in_json_format"></a>Docker output in JSON format<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/logging.asciidoc">edit</a>
</h4>
<p>All Docker console logs are now in JSON format. You can distinguish logs streams with the <code class="literal">type</code> field.</p>
<h4>
<a id="_audit_plaintext_log_file_removed_json_file_renamed"></a>Audit plaintext log file removed, JSON file renamed<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/logging.asciidoc">edit</a>
</h4>
<p>Elasticsearch no longer produces the <code class="literal">${cluster_name}_access.log</code> plaintext
audit log file. The <code class="literal">${cluster_name}_audit.log</code> files also no longer exist; they
are replaced by <code class="literal">${cluster_name}_audit.json</code> files. When auditing is enabled,
auditing events are stored in these dedicated JSON log files on each node.</p>
<h3>
<a id="breaking_70_node_changes"></a>Node start up<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/node.asciidoc">edit</a>
</h3>
<h4>
<a id="_nodes_with_left_behind_data_or_metadata_refuse_to_start"></a>Nodes with left-behind data or metadata refuse to start<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/node.asciidoc">edit</a>
</h4>
<p>Repurposing an existing node by changing node.master or node.data to false can leave lingering on-disk metadata and
data around, which will not be accessible by the node’s new role. Beside storing non-accessible data, this can lead
to situations where dangling indices are imported even though the node might not be able to host any shards, leading
to a red cluster health. To avoid this,</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
nodes with on-disk shard data and node.data set to false will refuse to start
</li>
<li class="listitem">
nodes with on-disk index/shard data and both node.master and node.data set to false will refuse to start
</li>
</ul>
</div>
<p>Beware that such role changes done prior to the 7.0 upgrade could prevent node start up in 7.0.</p>
<h3>
<a id="breaking_70_java_time_changes"></a>Replacing Joda-Time with java time<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h3>
<p>Since Java 8 there is a dedicated <code class="literal">java.time</code> package, which is superior to
the Joda-Time library, that has been used so far in Elasticsearch. One of
the biggest advantages is the ability to be able to store dates in a higher
resolution than milliseconds for greater precision. Also this will allow us
to remove the Joda-Time dependency in the future.</p>
<p>The mappings, aggregations and search code switched from Joda-Time to
java time.</p>
<h4>
<a id="_joda_based_date_formatters_are_replaced_with_java_ones"></a>Joda based date formatters are replaced with java ones<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>With the release of Elasticsearch 6.7 a backwards compatibility layer was
introduced, that checked if you are using a Joda-Time based formatter, that is
supported differently in java time. A log message was emitted, and you could
create the proper java time based formatter prefixed with an <code class="literal">8</code>.</p>
<p>With Elasticsearch 7.0 all formatters are now java based, which means you will
get exceptions when using deprecated formatters without checking the
deprecation log in 6.7. In the worst case you may even end up with different
dates.</p>
<p>An example deprecation message looks like this, that is returned, when you
try to use a date formatter that includes a lower case <code class="literal">Y</code></p>
<div class="pre_wrapper lang-text">
<pre class="programlisting prettyprint lang-text">Use of 'Y' (year-of-era) will change to 'y' in the next major version of
Elasticsearch. Prefix your date format with '8' to use the new specifier.</pre>
</div>
<p>So, instead of using <code class="literal">YYYY.MM.dd</code> you should use <code class="literal">8yyyy.MM.dd</code>.</p>
<p>You can find more information about available formatting strings in the
<a href="https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html" class="ulink" target="_top">DateTimeFormatter javadocs</a>.</p>
<h4>
<a id="_date_formats_behavioural_change"></a>Date formats behavioural change<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>The <code class="literal">epoch_millis</code> and <code class="literal">epoch_second</code> formatters no longer support
scientific notation.</p>
<p>If you are using the century of era formatter in a date (<code class="literal">C</code>), this will no
longer be supported.</p>
<p>The year-of-era formatting character is a <code class="literal">Y</code> in Joda-Time, but a lowercase
<code class="literal">y</code> in java time.</p>
<p>The week-based-year formatting character is a lowercase <code class="literal">x</code> in Joda-Time,
but an upper-case <code class="literal">Y</code> in java time.</p>
<h4>
<a id="_using_time_zones_in_the_java_client"></a>Using time zones in the Java client<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>Timezones have to be specified as java time based zone objects. This means,
instead of using a <code class="literal">org.joda.time.DateTimeZone</code> the use of
<code class="literal">java.time.ZoneId</code> is required.</p>
<p>Examples of possible uses are the <code class="literal">QueryStringQueryBuilder</code>, the
<code class="literal">RangeQueryBuilder</code> or the <code class="literal">DateHistogramAggregationBuilder</code>, each of them
allow for an optional timezone for that part of the search request.</p>
<h4>
<a id="_parsing_aggregation_buckets_in_the_java_client"></a>Parsing aggregation buckets in the Java client<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>The date based aggregation buckets in responses used to be of
type <code class="literal">JodaTime</code>. Due to migrating to java-time, the buckets are now of
type <code class="literal">ZonedDateTime</code>. As the client is returning untyped objects here, you
may run into class cast exceptions only when running the code, but not at
compile time, ensure you have proper test coverage for this in your
own code.</p>
<h4>
<a id="parsing-gtm0-timezeone-jdk8-not-supported"></a>Parsing <code class="literal">GMT0</code> timezone with JDK8 is not supported<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>When you are running Elasticsearch 7 with Java 8, you are not able to parse
the timezone <code class="literal">GMT0</code> properly anymore. The reason for this is a bug in the
JDK, which has not been fixed for JDK8. You can read more in the
<a href="https://bugs.openjdk.java.net/browse/JDK-8138664" class="ulink" target="_top">official issue</a>
This bug is fixed in JDK9 and later versions.</p>
<h4>
<a id="_scripting_with_dates_should_use_java_time_based_methods"></a>Scripting with dates should use java time based methods<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>If dates are used in scripting, a backwards compatibility layer has been added
that emulates the Joda-Time methods, but logs a deprecation message as well
to use the java time methods.</p>
<p>The following methods will be removed in future versions of Elasticsearch
and should be replaced.</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<code class="literal">getDayOfWeek()</code> will be an enum instead of an int, if you need to use
an int, use <code class="literal">getDayOfWeekEnum().getValue()</code>
</li>
<li class="listitem">
<code class="literal">getMillis()</code> should be replaced with <code class="literal">toInstant().toEpochMilli()</code>
</li>
<li class="listitem">
<code class="literal">getCenturyOfEra()</code> should be replaced with <code class="literal">get(ChronoField.YEAR_OF_ERA) / 100</code>
</li>
<li class="listitem">
<code class="literal">getEra()</code> should be replaced with <code class="literal">get(ChronoField.ERA)</code>
</li>
<li class="listitem">
<code class="literal">getHourOfDay()</code> should be replaced with <code class="literal">getHour()</code>
</li>
<li class="listitem">
<code class="literal">getMillisOfDay()</code> should be replaced with <code class="literal">get(ChronoField.MILLI_OF_DAY)</code>
</li>
<li class="listitem">
<code class="literal">getMillisOfSecond()</code> should be replaced with <code class="literal">get(ChronoField.MILLI_OF_SECOND)</code>
</li>
<li class="listitem">
<code class="literal">getMinuteOfDay()</code> should be replaced with <code class="literal">get(ChronoField.MINUTE_OF_DAY)</code>
</li>
<li class="listitem">
<code class="literal">getMinuteOfHour()</code> should be replaced with <code class="literal">getMinute()</code>
</li>
<li class="listitem">
<code class="literal">getMonthOfYear()</code> should be replaced with <code class="literal">getMonthValue()</code>
</li>
<li class="listitem">
<code class="literal">getSecondOfDay()</code> should be replaced with <code class="literal">get(ChronoField.SECOND_OF_DAY)</code>
</li>
<li class="listitem">
<code class="literal">getSecondOfMinute()</code> should be replaced with <code class="literal">getSecond()</code>
</li>
<li class="listitem">
<code class="literal">getWeekOfWeekyear()</code> should be replaced with <code class="literal">get(WeekFields.ISO.weekOfWeekBasedYear())</code>
</li>
<li class="listitem">
<code class="literal">getWeekyear()</code> should be replaced with <code class="literal">get(WeekFields.ISO.weekBasedYear())</code>
</li>
<li class="listitem">
<code class="literal">getYearOfCentury()</code> should be replaced with <code class="literal">get(ChronoField.YEAR_OF_ERA) % 100</code>
</li>
<li class="listitem">
<code class="literal">getYearOfEra()</code> should be replaced with <code class="literal">get(ChronoField.YEAR_OF_ERA)</code>
</li>
<li class="listitem">
<code class="literal">toString(String)</code> should be replaced with a <code class="literal">DateTimeFormatter</code>
</li>
<li class="listitem">
<code class="literal">toString(String,Locale)</code> should be replaced with a <code class="literal">DateTimeFormatter</code>
</li>
</ul>
</div>
<h4>
<a id="_negative_epoch_timestamps_are_no_longer_supported"></a>Negative epoch timestamps are no longer supported<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>With the switch to java time, support for negative timestamps has been removed.
For dates before 1970, use a date format containing a year.</p>
<h4>
<a id="_migration_guide"></a>Migration guide<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/migration/migrate_7_0/java_time.asciidoc">edit</a>
</h4>
<p>For a detailed migration guide, see <a class="xref" href="migrate-to-java-time.html" title="Java time migration guide">Java time migration guide</a>.</p>

</div>
<div class="navfooter">
<span class="prev">
<a href="breaking-changes-7.1.html">« Breaking changes in 7.1</a>
</span>
<span class="next">
<a href="migrate-to-java-time.html">Java time migration guide »</a>
</span>
</div>
</div>

                  <!-- end body -->
                        </div>
                        <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                        
                        </div>
                    </div>
                </div>
            </section>
        </div>
    </section>
</div>
<script src="../static/cn.js"></script>
</body>
</html>